1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, systems, and products for session replication.
2. Description of Related Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely complicated devices. Today's computers are much more sophisticated than early systems such as the EDVAC. The most basic requirements levied upon computer systems, however, remain little changed. A computer system's job is to access, manipulate, and store information. Computer system designers are constantly striving to improve the way in which a computer system can deal with information.
Information stored on a computer system is often organized in a structure called a database. A database is a grouping of related structures called ‘tables,’ which in turn are organized in rows of individual data elements. The rows are often referred to as ‘records,’ and the individual data elements are referred to as ‘fields.’ In this specification generally, therefore, an aggregation of fields is referred to as a ‘data structure’ or a ‘record,’ and an aggregation of records is referred to as a ‘table.’ An aggregation of related tables is called a ‘database.’
A computer system typically operates according to computer program instructions in computer programs. A computer program that supports access to information in a database is typically called a database management system or a ‘DBMS.’ A DBMS is responsible for helping other computer programs access, manipulate, and save information in a database.
A DBMS typically supports access and management tools to aid users, developers, and other programs in accessing information in a database. One such tool is the structured query language, ‘SQL.’ SQL is query language for requesting information from a database. Although there is a standard of the American National Standards Institute (‘ANSI’) for SQL, as a practical matter, most versions of SQL tend to include many extensions. Here is an example of a database query expressed in SQL:
select * from stores, transactionswhere stores.location = “Minnesota”and stores.storeID = transactions.storeID
A ‘transaction’ is a group or set of computer program instructions which must be executed atomically, that is, all or none. Consider an accounting entry, for example, a debit of a cash account and a credit of a sales revenue account. If the debit is effected without the credit, the accounts are unbalanced. The debit and credit are therefore wrapped in a transaction, in pseudocode, illustrated as this:
BEGIN  DEBIT CASH $25.00    CREDIT SALES $25.00COMMIT
The BEGIN command marks the opening of a transaction. The COMMIT command marks the end of the transaction. And the DEBIT and CREDIT are the commands to be executed atomically. If data processing of a transaction proceeds without error, a COMMIT command will succeed and return an indication of success to a calling program. If an error occurs, the COMMIT will fail, and the transaction will ‘rollback.’ That is, the effects of commands executed during the transaction are reversed, so that the entire transaction is undone, as if it never began. That is atomic execution of a transaction, all or nothing.
The Java programming environment provides transaction support for Java programs. In the state of the art, however, each transaction is executed separately. Each computer program instruction in a transaction, including the BEGIN and COMMIT instructions, represents an instruction to be issued from the Java environment to a DBMS. Each instruction within a transaction requires DBMS optimization and execution in the DBMS. Each separate transaction is also scoped as a transaction in the DBMS itself, incurring transaction processing overheads in the DBMS. Over millions of transactions, separate processing of each transaction therefore represents substantial inefficiency in data processing of transactions for Java programs.
The Hypertext Transfer Protocol (‘HTTP’) employed for web browser to web server requests is a stateless protocol. As a result, a web server has no means of associating a series of requests with a specific browser or user. The HTTP session API component of the Java Servlet specification provides a mechanism for web applications to maintain a client's state information, and this mechanism addresses some of the problems with other options for maintaining state, such as those based solely on cookies. This mechanism, known as a session, allows a web-application developer to maintain user state information on the server.
It's almost impossible to visit any interactive web site today that does not make use of the HTTP session API. By providing multiple options for tracking a series of requests and associating those requests with a specific user, HTTP session allows applications to appear dynamic to application users. The most often cited example of an HTTP session is the creation of a “shopping cart” for shoppers on a web site. In this example, information associating the user and their prior navigation through the web site and their selections are stored as objects in HTTP session. Once the users are ready to check out from the web site and purchase their selections, the application typically constructs a page composed of all the selected items stored in the “shopping cart.” By maintaining application state between browser requests, HTTP session overcomes the default stateless behavior for HTTP requests.
HTTP session replication is vital to almost every online business to maintain information about a user's session and provides a high quality of service to the end user. To maintain consistent uptime and provide a fault tolerant failover system HTTP session are often replicated either in a database or on another machine such as a peer application server in case a single machine fails, the client does not lose session data and can continue interaction with a service by having client requests routed to a different machine. Currently, however, most applications are CPU bound regarding the ability to replicate sessions effectively because of the overhead associated with serializing each session to be replicated followed by the actual process of transmitting the serialized session to either a database or a memory to memory replicated application server.